Change parsing to unify indirect call signatures with the same structure #177
Conversation
|
Hm, I'm not sure this is the best direction to go:
|
|
The problem is that even without this change, function declarations can implicitly add entries to the type table, and can be mixed in with explicit type table entries: IMO the text format needs to either use entirely implicit type indices or entirely explicit type indices to avoid exposing text format specific semantics like that. I personally prefer entirely implicit because it avoids the duplicate information in function declaration syntax, and it avoids giving the impression that you can meaningfully have multiple duplicate entries in the type table. |
|
I see, good point. I still don't think it's an option to not support an explicit type table -- the S-expression format is supposed to be a rendering of the AST, after all. Maybe the best solution is to not make function definitions contribute/refer to the type table. It seems to introduce more complication than benefit at this point; most functions will not be called indirectly anyway, so why bloat the table with their types? @lukewagner, WDYT? |
|
Good points. With unification, I agree that function definitions don't gain anything by being able to explicitly name an entry in the function table. So is there any benefit then of allowing explicit |
AndrewScheidecker
force-pushed
the
structural_call_indirect_signatures
branch
3 times, most recently
from
2a1643f to
c7a0595
Compare
This is meant to implement the changes discussed in WebAssembly/design#452. This eliminates the need to declare an explicit type reference for indirectly-called functions, so I also tried to eliminate the redundancy and potential mismatch between a function's type reference and its directly declared parameters and result, so I made any function declaration implicitly introduce a type matching its directly declared parameters and result. But this approach makes an explicitly indexed type table much less useful, since you no longer have complete control over its contents. To resolve that, I removed the declarations, and references to, type table entries. The type table is created implicitly from the set of unique types used by func and call_indirect. I also made the syntax slightly more uniform by defining a func_type production in the form (func_type ...), and using it in both call_indirect and import. I did not change func to use it, but I will submit another PR if people like this change.
AndrewScheidecker
force-pushed
the
structural_call_indirect_signatures
branch
from
c7a0595 to
266518b
Compare
|
I think we decided not to support in-place type expressions, since it has no correspondence to the binary format. Closing. |
This is meant to implement the changes discussed in WebAssembly/design#452.
This eliminates the need to declare an explicit type reference for indirectly-called functions, so I also tried to eliminate the redundancy and potential mismatch between a function's type reference and its directly declared parameters and result, so I made any function declaration implicitly introduce a type matching its directly declared parameters and result. But this approach makes an explicitly indexed type table much less useful, since you no longer have complete control over its contents. To resolve that, I removed the declarations, and references to, type table entries. The type table is created implicitly from the set of unique types used by
funcandcall_indirect.I also made the syntax slightly more uniform by defining a func_type production in the form
(func_type ...), and using it in bothcall_indirectandimport. I did not changefuncto use it, but I will submit another PR if people like this change.